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ABSTRACT 


Recent  advances  in  the  design  of  high  performance  aircraft,  such  as  fly-by-wire 
controls,  complex  autopilot  systems,  and  unstable  platforms  for  greater  maneuverability, 
are  all  possible  due  to  the  use  of  digital  control  systems.  With  the  aid  of  modem  control 
tools  and  techniques  based  on  state-space  methods,  the  aerospace  engineer  has  the  ability 
to  design  a  dynamic  aircraft  model,  verify  its  accuracy,  and  design  and  implement  the 
controller  within  a  matter  of  a  few  months.  This  work  examines  the  digital  control 
design  process  utilizing  a  Rapid  Prototyping  System  developed  at  the  Naval  Postgraduate 
School.  The  entire  design  process  is  presented,  from  design  of  the  controller  to 
implementation  and  flight  test  on  an  Unmanned  Air  Vehicle  (UAV). 
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INITIAL  DISTRIBUTION  LIST 


I.  INTRODUCTION 


The  use  of  digital  computers  in  the  real-time  control  of  aircraft  has  paved  the  way 
to  new  aircraft  designs  that  are  faster,  more  maneuverable  and  safer  than  ever  before. 
With  this  growing  emphasis  on  digital  control  design,  new  tools  and  techniques  have 
been  developed  to  aid  in  the  design  and  implementation  of  complex  control  systems. 
Traditionally,  control  systems  are  developed  using  classical  control  design  methods  that 
are  costly  and  time  consuming.  Newer  technologies,  like  rapid  prototyping  based  on 
modem  control  methods,  integrate  the  design  process  and  shorten  the  time  required  to 
complete  a  control  design  from  a  few  years  to  a  few  months. 

The  purpose  of  this  thesis  is  twofold:  develop  the  background  material  for  an 
Advanced  Control  of  Aerospace  Vehicles  course,  and  design  and  flight  test  an  altitude 
hold  controller  for  a  UAV. 

At  the  Naval  Postgraduate  School,  students  in  the  Aeronautical  and  Avionics 
Engineering  curriculum  receive  a  full  sequence  of  controls  courses  with  the  final  course 
being  Advanced  Control  of  Aerospace  Vehicles,  for  which  this  thesis  is  written.  This 
course  will  introduce  the  students  to  the  critical  aspects  of  the  design,  implementation  and 
flight  testing  of  the  basic  controllers  for  fixed-wing  aircraft.  The  course  examines  both 
classical  (transform)  and  modem  (state-space)  control  methods  for  designing  complex 
digital  control  systems. 

The  main  focus  is  on  the  study  of  sampled-data  systems,  systems  that  have  both 
discrete  and  continuous-time  components.  Devices  used  for  the  interface  between  the 
continuous  and  discrete  components,  the  analog-to-digital  converter  and  the  digital-to- 
analog  converter,  are  covered  in  detail.  This  thesis  will  derive  mathematical  models  for 
each  of  these  operations,  and  develop  tools  for  analysis  and  synthesis. 

The  class  is  largely  project  oriented.  Much  of  the  class  is  concentrated  in  the 
Avionics/Controls  laboratory  and  the  Unmanned  Air  Vehicle  (UAV)  laboratory.  The 
projects  are  centered  on  a  Rapid  Prototyping  System  (RPS)  developed  by  the  aeronautical 
engineering  department  for  flight  testing  control  algorithms  for  unmanned  air  vehicles. 
The  system  affords  a  small  team  the  ability  to  test  new  concepts  in  guidance,  navigation, 


1 


and  digital  control.  The  RPS  consists  of  commercially  available  rapid  prototyping 
software  with  an  open  architecture  design  to  allow  for  a  wide  range  of  applications.  The 
application  software  developed  by  Integrated  Systems  Incorporated  (ISI),  called  RealSim, 
allows  students  to  participate  in  design  projects  from  the  initial  concept  stage  to  the  flight 
testing  phase  of  the  design  process.  This  software  has  two  main  advantages: 

•  The  ability  to  automatically  generate  higher-language  code  such  as  C  for  the 
designed  controller. 

•  The  system  utilizes  industry  standard  I/O  devices  including  digital-to-analog, 
analog-to-digital,  pulse  width  modulation,  and  serial  capability,  permitting  easy 
connections  to  hardware. 

The  test  bed  aircraft  used  is  a  UAV  called  FROG  ,  shown  in  Figure  1.1.  This  UAV  is 
equipped  with  a  complete  avionics  suite  necessary  for  autonomous  flight. 

The  accomplishment  of  this  endeavor  has  led  to  a  number  of  successful  projects, 
including  voice  controlled  flight  and  an  airspeed  controller,  and  is  paving  the  way  for 
more  complex  projects  such  as  autonomous  landing.  This  thesis  will  describe  in  detail 
one  such  design  project,  the  development  of  an  altitude  hold  controller  implemented  in 
the  FROG  using  the  RPS  tools.  The  automation  of  the  design  process  is  completed  in 
three  developmental  phases: 

•  Feedback  controller  design.  In  this  phase  a  model  of  the  plant  is  created.  The 
controller  is  then  designed  through  various  methods  of  classical  input/output 
control  techniques  and/or  modem  state-space  control  techniques.  The  process 
typically  involves  many  iterations  to  satisfy  specific  design  requirements. 

•  Hardware-In-the-Loop  Testing.  The  feedback  system  is  tested  with  some  or 
all  of  the  actual  hardware  which  will  be  used  to  control  the  aircraft.  This  is  the 
final  validation  of  the  controller  prior  to  an  actual  flight. 
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•  Implementation  and  Flight  Test.  The  controller  is  implemented  in  the  Fight 
Management  System  used  to  control  the  FROG  and  then  flight  tested. 

The  design  process  described  above  is  completed  entirely  with  the  Real  Sim  series  rapid 
prototyping  software  and  real-time  control  hardware  integrated  with  the  system. 


Figure  1.1:  UAV  FROG 


II.  SAMPLED-DATA  SYSTEMS 


The  systems  and  signals  studied  in  the  control  of  aerospace  vehicles  are  referred 
to  as  sampled-data  systems  and  have  both  discrete  and  continuous  components,  see 
Figure  2.1,  where  a  continuous-time,  or  analog  signal,  is  to  be  processed  using  a 
computer  or  special-purpose  Digital  Signal  Processing  (DSP)  chip  set.  The  interface 
between  the  continuous  and  discrete  systems  include  the  analog-to-digital  (A/D)  and  the 
digital-to-analog  (D/A)  converters. 


u(k) 

Zero-Order-Hold 

u(t) 

Plant 

y(t) 

w 

Sampler 

y(V 

W 

(D/A) 

(CTS) 

(A/D) 

- p. 

Figure  2.1:  Sampled-Data  System 

The  conversion  of  the  a  discrete  to  an  analog  signal  by  the  D/A  converter,  which 
usually  uses  a  Zero-Order-Hold  (ZOH),  involves  scaling  the  digital  values  and  converting 
them  to  a  piecewise-constant  continuous  output.  Where  the  conversion  of  the  analog 
signal  to  a  discrete  sequence  by  the  A/D  converter  is  accomplished  by  a  sample-and-hold 
circuit,  called  a  Sampler. 

This  chapter  will  describe  the  operations  of  the  digital-to-analog  converter  and 
analog-to-digital  converter  and  methods  for  obtaining  discrete  models  of  continuous-time 
systems.  Material  presented  in  this  chapter  is  in  the  form  of  classroom  notes,  for  further 
discussion  refer  to  [Ref.  1,2,3]. 

A.  DISCRETE  MODELS  OF  SAMPLED-DATA  SYSTEMS 

In  this  section  we  establish  a  general  method  for  obtaining  the  difference 
equations  that  represent  the  behavior  of  the  sampled-data  system.  The  resulting 
equivalent  discrete  system  will  then  be  analyzed  using  the  sample-to-sample  discrete 
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transfer  function  of  a  continuous  system  between  a  D/A  and  an  A/D,  as  shown  in  Figure 


u(k) 


2.2. 

Where 


P  = 


jx  =  A- x  +  B -u 
\y  =  C  -x  +  D-u 


Pj  = 


xk+ 1  =Ad-xk  +  Bd-uk 
yk  =Cj-xk  +  Dd-uk 


Figure  2.2:  Equivalent  Sampled-Data  System 


1.  Digital- to-Analog  Converters  (D/A) 

Digital-to-analog  converters  usually  use  zero-order  hold  or  (ZOH):  given  a 
sequence  of  samples,  u(kT)  at  t  =  kT ,  and  holding  its  output  constant  at  this  value  until 
the  next  sample  is  taken  at  /  =  kT  +  7  to  produce  a  continuous  signal.  The  piecewise 
constant  output  of  the  D/A  is  the  signal  u(t)  that  is  applied  to  the  plant.  Thus,  the  value  of 
u(t)  consists  of  steps  as  seen  in  Figure  2.3. 
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2.  Analog-to  Digital  Converters  (A/D) 

The  analog-to-digital  converter  samples  the  analog  signal  y(t)  at  discrete  times  and  passes 
them  to  the  computer.  The  time  interval  between  samples  yu  is  called  the  sampling 
interval  T.  The  A/D  converter  has  two  functions:  quantizing  the  sampled  analog  signal 
into  a  discrete  set  of  levels  and  coding  the  quantized  representation  into  an  acceptable 
format. 


Input 


Output 


u(t) 

r 

T  IT 

0 

3 T  47*  5 T 

Output 


Digilal-to -Analog 
Converter 
(DAC) 


Figure  2.3:  Digital-to-Analog  Conversion 


3.  Discretization  of  Continuous-Time  Systems 


Consider  a  linear,  continuous-time  system 


then 


A-x  +  Bu 
C-x  +  D-u’ 


I 

x(t)  =  eA(-'a)  ■  x(t„)+  jeA{,~T)  ■  B-  u(t)  ■  dr . 

to 

To  discretize  let:  to  —  kT ;  t  =  kT  +  T  and  assuming  u  is  held  constant  over  the  sampling 
interval  T  (ZOH  with  no  delay) 

u(t)  =  u(kT)  ;  [kT  <  x  <kT  +  7] 


Then 


kr+T 

x(kT  +  T)  =  eA(T)  ■  x(kT )  +  jeA(kr+r-T)  •  B  ■  u(t)  ■  dr 

kT 
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Let 


then 


$  =  (kT  +  T)-x 

d$  =  -dr, 

r  =  kt=$%=T 
t  =  kT  +  T  =>  £  =  0 


Let  x(kT+T)  =  xk+] ,  then 


1 

**.,  =  e"-x„  +  Je«  .B-u„- rff 


Define 


<E>  =  eAT 


The  discrete  equivalent  of  P 


Pj  = 


i 

T=  \eA4Bdt 


xk+ 1  =®xk  +r-w* 


(Eq.  2.1) 


l«  =  C-»,  +D-Ut  (Eq'2-2) 

Note  the  equivalent  discrete  system  is  shift-invariant,  since  <t>  and  T  are  not  functions  of 
k.  Commands  to  discretize:  Matlab~c2d,  Xmath-discretize 


EXAMPLE  2.1:  Discretize  the  following  CTS 


x  = -a- x  +  a-u 
y  =  x 


P(s)  = 


a 


s  +  a 


From  equation  2.2 


0)  =  e~ar 

T 

r=  fe-“f  -(a)-d^  =  (l-e~aT) 


xk+ 1  =e~aT-xk  +(l-e~a,)-u 


-a-Ts 


yk=xk 
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B.  THE  Z-TRANSFORM 


1.  Definition 

Given  a  sequence  {jc*},  k  =  oo  ,  let 

00 

X(z)  =  Y^xk  • Z_A >  ro  <  \z\  <  Ro ,  (Eq.  2.3) 

*=-oo 

where  we  assume  we  can  find  values  of  r0  and  for  which  the  series  converges. 

As  in  the  case  of  the  Laplace  transform,  Eq.  (2.3)  is  considered  an  operator  that 
transforms  a  sequence  xk  into  a  function  X(z),  symbolically  represented  by 

X(z)  =  Z{xk} 

The  Xk  and  X(z)  are  said  to  form  a  z-transform  pair  denoted  as 

X(z)  Z{xk) 


EXAMPLE  2.2  Consider  the  sequence  given  in  example  problem  2. 1 


a 


P(s)  = 

s  +  a 

By  Eq.  (2.3)  the  z-transform  of  Xk  is 


Xk  =  e 


-akT 


k=0,l,2,.. 


Z{xt }  =  X{z)  -  Y,e-"z~k  =  J(e-"r  -z~') 

k= 0  *=0 

Note:  a  infinite  geometric  sum  is  given  by 

S»  =  i>-=-L  ;  |«|<1 

m- 0  1  & 

Letting  a  =  ( e~aT  ■  z~x ) 


X(z)  = 


e  aI  •  z  1  <  1  ;  z  >  e 


\-{e~aT  -z~') 


-aT 


2.  Some  Properties  of  the  z-Transform 

Listed  below  are  some  properties  of  the  z-transform  useful  to  the  material 
presented  in  this  section.  For  reference,  a  more  complete  list  is  found  in  [Ref.  1], 
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Linearity:  given  {xkj,  {yk} 


Z(xk+y/J  =  Z(xk)  +  Z(y0 

Z[a(xk  +  yk)]  =  Z(ax0  +  Z(ay0  =  a X(z)  +  a  Y(z )  ;  where  a  =  constant 


Time  Shifting: 

Gives  transform  pairs 

Demonstrated  by 


Z{x(k±n)}  =z±nX(z) 

x(k+j)  <r>zX(z) 
x(k-l)  <-»  z'1  X(z) 

Z  (  xk+ j)  z  (x/^) 

z  ( Xk+, )  =  -z~k  =  jr*A+1  • z~k'M 

0  0 

•*■“*"•* 

0 

=  z-X(z) 


Final  Value  Theorem: 

Lim  x(k )  =  Um  (z  -  \)X  (z) 

k->  co  z->l 

if  such  limits  exists. 


EXAMPLE  2.3:  Find  the  z-transform  given  in  example  problem  2.1. 

7  lxk+\  =  e~OT  ' +  (1 

U  -*. 

zX(z)  =  e-a'  ■X{z)  +  {\-e-aT).U{z)\  Y{z)  l-e~°T 
Y(z)  =  X(z)  \U(z)  z-e~aT 
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C.  ANALYSIS  OF  DISCRETE-TIME  SYSTEMS 


1.  The  Discrete  Transfer  Function 

Consider  the  continuous-time  and  discrete-time  systems  shown  in  Figure  2.4. 


u(t) 


y(t) 

u(k) 

p 

- ► 

- ► 

pd 

Figure  2.4:  System  Transfer  Functions 


The  transfer  function  for  the  continuous-time  system  is 

Y(s)  =  {C(s/  -  A)'1  B  +  d}-  U(s) 
For  the  discrete-time  system  compute 

Jxk+ 1 

1  yk=c-xk  +D-uk  J 


z(xk+])  =  z(<s-xk+r-u) 

z-X(z)  =  0-X(z)  +  -r-U(z) 

x(z)  =  (zi-<t>)-]  -r-u(z) 

Z(yk)  =  Z(C-xk+  D-uk) 

Y(z)  =  C  ■  X(z)  +  D-U(z) 

Y(z)  =  {c-(zl-  <D )-'  •  r  +  d)  ■  U(z ) 

'  Td  ' 

Discrete  transfer  function 

^l=c-(z/-<Dr'-r+z) 

U(z) 

EXAMPLE  2.4:  Find  the  discrete  transfer  function  from  example  problem  2.1 
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Given: 


P(s)  = 


s  +  a 


Continuous-Time 


Discrete-Time 


a 


From  Eq.  (2.4) 


Y(s)  =  [C  •  (si  -  AY  • B  +  D ]  •  U(s)  =>  Y(s )  =  •  U(s) 

s  +  a 


/ 

O  =  r  r  =  \ea  *  •  (a)</£  =  (1  -  e-T) 


—  =  (l)[z/  -  e-T  r1  •  (1  -  e-T )  =  -LlL. 


U(z )  z-e 

Now  consider  the  sampled-data  system  in  Figure  2.5. 


Let 


Figure  2.5:  Prototype  Sampled-Data  System 

[\\k  =  0 

u(kT)  =  - 


[0;&  ^  0 

Then  u(k)  is  the  unit  impulse.  The  response  to  a  unit  impulse  determines  the  impulse 
response  of  the  D/A  converter: 

«(0  =  i(0-i(f-r) 

Then 

-sT 


U(s)  =  --—  =  -( 1 -e-'r) 
s  s  s 


and 


X0  =  i_l^(l-e-r)j 

y(kT)  =  y(t),  (, k-\)T<t<kT 
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Finally, 


G(z)  =  Z(y(kT)) 


=  Z\L 


,r  <*) 


.(i-,-) 


=  (i-z~')-z<|r1 
=  (i-z-').z| 


-In  -71  ^0) 


\ 


J 


Where  the  UL'1  ”  is  dropped  for  convenience. 

EXAMPLE  2.5:  Compute  the  discrete  transfer  function  for 

a 


GO)  = 


s  +  a 


Then 


The  corresponding  time  function 


G(s )  1  1 


5  s  s  +  a 


y(kr)  =  \(kT)-e-"‘,l(kT) 


The  z  transform 


Z{^|  =  Z(y(kT))  = 


z  _  z(l  -  e  ) 


From  equation  2.5 


G(z)  =  (1  -  z  ) 


z  1  z-e  *  (z-i)(z-e  aT) 

z(\-e-r)  } 


fz-lXz-e") 


l-e 


-aT 


z-e 


-aT 


(Eq.  2.5) 
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The  transfer  function  can  also  be  obtained  from  the  system’s  response  to  a  unit 
pulse.  Suppose  the  system  input,  uk  for  k  >  0,  and  the  initial  conditions  are  known,  then 
writing  out  each  term  of  the  difference  equation  gives: 

x,  =  G>  •  x0  +  T  •  u0 

x2  =o-x,+r-w1  =<t>-(o-x0+r-M0)+r-M,  =  o2-x0  +  a>-r-w()+r-w1 
xk  =  <£>k  -x0  +  <frk~'  -r-M0  +<D*"2  -r-w,  +...T •«*_, 

Therefore, 

x,  =  o*-x0+][V-'-r-w, 

*-i  (Eq.  2.6) 

jt=co‘x,+y.c  -f-'-r-u, 

h/k-i) 

Suppose  xo  =  0  and 

Jl;£  =  0 
~  [0\k  *  0  ’ 

then 

k 

yk  =  'u,  =  hd(k). 

<=0 

In  general, 

co 

k=-cn 

2.  Block  Diagrams  and  State-Space  Descriptions 

The  discrete  transfer  function,  in  the  z-domain,  represents  a  linear  algebraic 
relationship,  accordingly  multiple  linear  systems  may  be  described  by  a  system  of  linear 
equations. 
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Parallel  Connections:  The  system  response  of  a  parallel  combination  of  two  LTI 
systems  is  the  sum  of  the  single-path  transfer  function,  Figure  2.6. 


u 


►  H,(r) 


H2(z) 


J 


Figure  2. 6:  Parallel  blocks 


m  =  [Ht  (z)+  H2  (z)]  ■  U(z)  =  H(z)  •  U(Z) 

W)  ' 


Cascade  Connections:  The  system  response  of  two  LTI  systems  in  series  is  related  by 
the  product.  Figure  2.7. 


u 


> 


H,(z) 


> 


H  2(z) 


— ► 


Figure  2.7:  Cascade  blocks 


T(z)=//2(z)^(z)J 


Y(z)=  H}(z)-  H2(z)-U(z) 


Feedback  Connections:  The  transfer  function  of  a  single  loop,  Figure  2.8,  is  given  by: 


■o 


H  ,(z) 


H2(z) 


Figure  2. 8:  Feedback  transfer  function 
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Figure  2.9:  State-Space  Realization 

By  inspection 

x,(A:  +  l)  =  x2(k) 
x2(k  +  \)  =  x2{k) 

xz{k  +  X)  =  -bx  -x3(k)-b2  -x2(k)-b3 -xx(k)  +  u 
y  =  ax  ■x3{k)  +  a2  •  x2(k)  +  a3  ■  xx(k) 
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In  vector-matrix  form 


*(£  +  !)  =  0-x(£)  +  r-w(£) 


y(k)  =  C  •  x(k ) 

C  —  [«3  a2  a,] 

3.  Input/Output  Stability 

Suppose  |ma|  <  M  <  oo ,  for  all  k  >  0,  then  Pd  is  BIBO  stable  if  in  response  to  any 

bounded  input  uk ,  the  output  yk  is  also  bounded:  \yk  \  <  oo ,  for  k  >_0. 

In  general,  for  zero  initial  conditions,  [  x(0)~0  ] 

oo 

yk  = 

k=- oo 

For  BIBO  stability 

\y„ |=  t,hd(k-i)M  < 

£=-00  £=-00 

<M-Y\hd(k-i)\<«> 

if 

Sk(£-O|<oo  or  J]|A(A:)|<00 

£=-oo 

Therefore,  if  the  unit  pulse  response  is  absolutely  summable,  then  the  system  is  BIBO 
stable. 

EXAMPLE  2.6:  Determine  the  stability  requirements  for  example  problem  2.1. 

Consider  the  unit  pulse  response 
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k=0, 1,2,3  ...oo 


yk  =hj(k)  =  ak 


and 


1 


l-\a 


is  BIBO  stable  if  \a\  <  1 ,  and  unstable  otherwise. 


D.  SIGNAL  ANALYSIS  AND  DYNAMIC  RESPONSE 


1.  Signal  Transforms 

The  unit  pulse: 

U(z)=  f>»T-'=Z°=l  ; 

k=-co 

The  unit  step: 

U(z)=±ut-z->=£2-‘=-±-_ 

k—-  oo  k--x  I  2 


“k  = 


\\,k  =  0 

!(U*o 


General  sinusoid: 


uk  =rk  ■  cos (k0)  •  1(&)  =  rk 


z- 1 


(e*e 


uk  = 


[l;jfc>0 

|0;£  <  0 


i(*) 


Z[rk  ■  cos(kO)  ■  1(&)]  =  i 


2  Z 

•  +  — 


z  —  re'6  z  —  re 


U(z)  =  z(z~rcos^) 

22  -  2r (cos 0)z  +  r2 


2.  Frequency  Response  of  DTS 

Consider  a  sinusoid  at  frequency  ©0  applied  to  a  continuous-time  system 

u(t)  =  A  ■  cos(co0  •/) 

The  continuous-time  response  is 
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3.  The  Discrete  Fourier  Transform  (DFT) 

Let  the  time  function  be  periodic,  i.e.  f(kT)=f(kT+NT),  then  DFT  of f(kT)  can  be 
defined  as: 

N^f{kT^.e~i2^nkT)l^ 

k= 0 
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where  F(n)  is  a  z-transform  of  the  f(kT)  over  one  period  evaluated  at  the  discrete 
frequencies  of  a  Fourier  series  z  =  eJtoT ,  where  a>  =  .  Define  Fn  =  F(2m/  NT) , 

Then  the  DFT  can  be  rewritten  as 


F. 

k-0 

and  the  inverse  transform  is 


fk=~YJFl  eJ'2^nlc^  N 
N  n= o 

Now  evaluating  the  frequency  response  using  the  DFT  can  be  done  as  follows: 
Let 


Then 


u(kT )  =  A  sin 


Inlk 

~N~ 


(O,  = 


2  nl 
~N 


V*  =  Z^'sin| 


2  idk 
N 


-j2mk/N 


=  —  ■'£  ~n)/N  _  e~j2xk(l+n)/N  j 


0;/  &  n 
=  \  NA 


[V 


;l  =  n 


and  the  DFT  of  the  output  is 


y{kT)  =  B-  sin 


2  idk 

~n 


■  +  y/ 


N- 1 


r„=ZB'sin! 


k= 0 


2  nlk 
~N 


+  ¥ 


-j2mk/N 


AW 

0;/  *  n 

——  ‘,1  =  n 

V 


iW  .J2xk(l-n)/N_-jy/  -j2nk(l+n)/N 
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Therefore  the  transfer  function  for  co,  = - is  defined  by 

1  NT 

where  7/  =  FFT(yT)  and  U/  =  FFT  (u/J,  evaluated  at  n=l. 

Jej27dlN\=  Y,  Be » 

V  J  U,  A 

E.  SAMPLED-DATA  SYSTEMS  ANALYSIS 

For  the  purpose  of  studying  the  sampled-data  systems,  each  operation  involved 
will  be  analyzed  separately.  First  consider  the  ideal  sampler  shown  in  Figure  2.1 1.  The 
technique  presented  here  is  to  use  impulse  modulation  to  form  the  mathematical 
representation  for  the  process  of  taking  periodic  samples  from  r(t)  to  produce  a  sequence 
r(kT)  and  to  analyze  the  sampled  signal  as  a  continuous  signal  using  the  Lapace 
transform. 


Figure  2.10  :  Ideal  Sampler 


The  output  of  the  sampler  is  a  train  of  impulses 

00 


r\t)=  £ r(t)-8(t-kT ) 

k=-  oo 

Recall  the  following  properties  of  the  unit  impulse 

00 


^f(t)-8(t-  a)dt  =  f  ( a )  sifting  property  and 


Therefore 


\5{r)dr  =  1(f) 


21 


L{r’(0}= 

—  OO 

00  OO 

=  j£Kr)£(r-*r)-e~vrJz- 

_coAr=-oo 

=  E  \{r)5{t-kT)-e-ST  -dr 

k=-<x>  „00 

=  E''<t7')e"'*T  =  *'(*) 

where  we  used  the  sifting  property  of  8 . 

Now  consider  the  hold  operation,  which  takes  the  impulses  produced  by  the 
sampler  and  extrapolates  the  data  into  a  piecewise  constant  output  rh,  as  shown  in  Figure 
2.12. 


r(t) 


r*(t) 


ZOH 


Figure  2.11:  Sample  and  Hold 


Using  zero-order  polynomials,  thus,  the  name  zero-order  hold  (ZOH),  which  hold 
each  sample  constant  over  the  sampling  period,  the  piecewise  signal  rh  is  defined  as 

rh  =  r(kT)  ;  kT<t<(k+l)T 

The  response  of  the  ZOH  to  a  impulse  at  time  t=0  is  1  for  0  <  t  <  T.  The  impulse 
response  of  the  ZOH  is  ZOH(t)=l(t)-l(t-T).  Therefore, 

ZOH(s)  =  J[l(/)  -  l(r  -  T)\e~s'  ■  dt  =  (1~g  ST) 

0  S 

1.  Spectrum  of  a  Sampled  Signal  and  Aliasing 

Since  r  (t)  is  a  periodic  function  it  has  a  Fourier  series  representation: 

E  S(t-kT)=  E  C,  ■eM!~IT>'  -  Ec„ -e^" 
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where 


Therefore, 


1  r'}  “ 

c.=z  I  £<S(< 


jn(2x/T)-l 


dt 


_T  /  2  k=-vo 


T 


2  n 


Yl5(t-kT)  =  -YjeKlmir)l 

f  n=-co 


k~- oo 


Let  cos  =  —  ,  be  the  sampling  frequency  and  take  the  Laplace  transform  of  the  sampler 


output: 


L(r’(t))=  T  fjr(t)-d(t-kT))e-'ldt 

t\n-~co 


=  JK0|  J^Y'dt 


Let  5  =jco 


1  00 

=  f(0  e^'-e-dt 


T 

±  n=- «>„«> 


1 


T  Y,R^-jncos) 

«=r— on 


R*  O'® )  =  Z  *0’®  _  Jno)s ) 

«=— QO 


Notice,  that  sampling  produces  an  infinite  train  of  sidebands  at  ncos ,  n  =  -oo . . .  oo . 


EXAMPLE  2.7:  Let  ci*  =  1,  coj  =  1/8 

i?*0'l/8)  =  ...  +  R(ja >, )  +  £[/(<»,  -  to, )]  +  R[j(co2i  -  cos )]  +  ... 
= ...  +  R(j\/%)  +  R[j(-7  /  8)]  +  R[j(- 14/8)]  +  ... 


If  R(jco)  has  components  above  the  Nyquist  frequency  o)J2  or  n/T,  then  after  sampling 
overlap  or  aliasing  will  occur  and  the  original  signal  can  not  be  reconstructed.  This  leads 
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to  the  sampling  theorem:  the  original  signal  can  be  recovered  from  its  samples  if  the 
sampling  frequency  (cos  =  2n/T)  is  at  least  twice  the  highest  frequency  in  the  signal.  To 
avoid  aliasing  a  low-pass  anti-alias  filter  is  usually  inserted  preceding  the  sampling 
operation. 


2.  Data  Extrapolation 

To  recover  R(ja>)  pass  R*  through  a  low-pass  filter  L(ja>)  as  shown  in  Figure 

2.12. 


R(jco)  =  L(ja>)  R*(jco) 


\uj4 

T 

J 

L 

•  £  It  (0 

T  ~ 


Figure  2.12:  Ideal  Lowpass  Filter 

Then 

.  x/r 

l(t)  =  —  [t  eialdco 

^ n  -n IT 

_  I_  fcK*nr) 

2  njty 

1  .  7Tt 

= - sin  — 

MIT  T 

.  rt 

=  sine  — 

T 

Therefore, 

oo 

r(t)  = 

—oo 
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=  J^r(r)-£(r-&r)-sinc— — — dr 

-xjc=- to  T 

V>  /7  ^  .  Jc(t  —  kT ) 

=  2_,  r(*T)smc— - - 

*=-00  T 

Note,  the  ideal  extrapolator  is  noncausal,  since  l(t)  is  nonzero  for  t  <  0.  Suppose  L(jw)  is 
replaced  by  ZOH. 

Recall, 

l-e~JtoT 

ZOH  (jco)  =  — 7 - . 

J0> 


Expressing  the  transfer  function  in  magnitude  and  phase  form 

.  f  coT'' 
nnc 


ZOH  {jco)  =  T  •  e" 7  sine 


V  2 


Therefore, 


|ZO//(»|  =  T 


sine 


ox[_ 

2 


ZZOH(jco)  =  — — —  + 1 80  •  S(co  -  riln) 

The  resulting  signal  contains  unwanted  harmonics  or  impostors.  By  frequency  analysis 
of  r(t)  the  principal  harmonic  can  be  identified. 

Consider  the  sinusoid  signal  v(t)  =  eJO>"'+l* 

V(jco)  =  .  ~j cat df 

-co 

00 

This  integral  is  not  defined,  however  notice  Z(8(t))  =  je~Jal  •  S(t)  ■  dt  =  1 , 
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Now  replace  t  with  a>  to  get 


Therefore, 


S(a>)  = 


_1_ 

2k 


\eico,dt 


-00 

=  2 m  ’*  8(co-co0 ) 


Since  8  is  a  even  function,  the  spectrum  of  r(t)  can  be  written  in  terms  of  impulse 
functions 

R(jco)  =  TjA^^dico  -co0)+ e~J*S(o)+ ty0)] 

To  recover  the  signal  Rh  ,  multiply  the  spectrum  of  R*  by  the  transfer  function  of  the 
ZOH. 


F.  DISCRETE  EQUIVALENTS  BY  NUMERICAL  INTEGRATION 

Concept:  Represent  a  given  continuous  transfer  function  H(s)  as  a  differential 
equation  and  derive  a  difference  equation  whose  solution  is  an  approximation  to  that  of 
the  differential  equation. 

1.  Numerical  Integration 

When  considering  discrete  approximation  to  integration,  as  shown  in  Figure  2.13, 
three  alternatives  exist. 


Forward  Backward  Trapeziod 


Figure  2.13:  Area  Approximation  Rules 
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Approximation  methods: 

Forward: 

zK+i  =xk  +T-(uk)} 


zX(z)  =  X(z)  +  T  •  U(z)  1  =  X(z)  =  T 

X(z)(z-l)  =  T-U(z )  £/(z)  z-1 

5  is  replaced  by  -» 


Backward: 

z(**  =**-i  +  ?’•«*} 

X(2)  =  Z-1X(2)  +  7’-t/(2)^//(2)  =  ^M  = - T 

U(z)  (1-z1) 

5  is  replaced  by  — >  ~~ 

Trapezoid  Rule  (Tustin’s  Method): 

T 

zixk  =  xk-i  +  --(w*  ~uk- 1)} 

2  t/(z)  2  1-z'1  2  z  —  1 

5  is  replaced  by  -»  —  - — - 
Tz  + 1 

Therefore,  given  a  continuous  transfer  function  H(»  a  discrete  equivalent  can  be 
found  by  the  substitution: 

H,  (?)  =  H(S) |  .v=(2/7')[(z-l)/(r+l)] 
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2.  Zero-Pole  Mapping  Equivalents 

This  technique  consists  of  a  set  of  rules  for  locating  the  zeros  and  poles  and 
setting  the  gain  of  a  z-transform  that  will  describe  a  discrete,  equivalent  transfer  function 
that  approximates  the  given  H(s). 

Rule  #1:  All  poles  of  H(s)  are  mapped  by  z  =  esT.  Replace  s  with  esT  for  the  poles  of 
H(s).  If  H(s)  has  a  pole  at  s  =  a,  then  H(z)  has  a  pole  at  z  =  eaT.  If  H(s)  has  a  complex 
pole  at  s  =  -a  +  jb,  then  H(z)  has  a  pole  at  z  =  re±  l(> . 

Rule  #2:  All  finite  zeros  are  mapped  by  z  =  esT. 

Rule  #3:  All  infinite  zeros  of  H(s)  are  mapped  by  z  =  -1. 

a)  Only  one  zero  of  H(s)  at  s  =  oo  is  mapped  into  z  =  oo. 

Rule  #4:  The  gain  of  the  digital  filter  is  selected  to  match  the  gain  of  H(s)  at  the  band 
center. 

H(s  =  0)  =>  Hd(z  =  1) 


3.  Zero-Order  Hold  Equivalent 

If  the  approximating  hold  is  the  ZOH,  then  the  equivalent  to  H(s)  is 

tf(z)  =  (l-r-')zj^j 

This  is  the  same  relationship  that  was  derived  earlier  in  section  C  of  this  chapter. 
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III.  INTRODUCTION  TO  RAPID  PROTOTYPING 


The  primary  tool  for  the  research  conducted  in  the  Avionics  lab  is  the 
hardware/software  interface  provided  by  the  MATRIX,  product  family  developed  by 
Integrated  Systems  Inc.  (ISI).  The  MATRIX,  product  family  is  shown  in  Figure  3.1. 
This  software  provides  a  complete  workbench  for  control  systems  design  and 
implementation.  The  RealSim  controller  automates  the  development  of  the  real-time 
systems  by  combining  graphical  modeling  software  with  real-time  control  hardware.  The 
key  feature  of  this  product  is  the  AutoCode  tool  which  will  automatically  program 
higher-language  code  such  as  C  or  ADA  for  the  designed  controller.  The  software 
consists  of  an  easy  to  use  graphical  user  interface  (GUI)  that  can  be  run  on  either  SUN 
workstations  or  a  PC.  The  interface  interacts  with  a  high-speed  digital  signal  processing 
(DSP)  board  developed  by  Texas  Instruments.  The  system  is  called  AC-100  Model  C30. 


Figure  3.1:  MATRIX,  Product  Family 
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A.  RAPID  PROTOTYPING  SYSTEM  ARCHITECTURE 


The  rapid  prototyping  system  architecture  consists  of  a  UNIX  workstation  and  a 
windows  based  PC  host  computer  which  is  equipped  with  two  ISA  bus  adapter  boards 
(Figure  3.2).  The  workstation  and  PC  are  connected  through  Ethernet,  using  the  standard 
TCP/IP  protocol  suite.  The  two  hardware  boards  in  the  PC  consist  of  a  board  which  acts 
as  the  motherboard  for  the  C30  DSP,  and  a  “DSPFLEX”  carrier  board  which  holds  four 
input/output,  or  “IP”,  modules.  The  I/O  boards  connect  the  model  to  the  real  hardware 
via  the  Hardware  Connection  Editor  (HCE),  which  will  be  discussed  in  later  sections.  The 
complete  system  is  referred  to  as  the  AC- 100  Model  C30  real-time  controller. 

The  avionics  lab  currently  has  two  PC’s  configured  as  described  above:  a  Pentium 
tower  PC  called  America  and  a  luggable  PC  called  AC  100.  The  luggable  PC  is  normally 


Figure  3. 2  :  RealSim  Architecture 
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connected  to  a  stand  alone  Sparc  II  workstation,  used  for  field  fight  testing  with  the 
school’s  Unmanned  Air  Vehicle  (UAV)  called  FROG. 

There  are  a  number  of  different  types  of  I/O  cards  available  depending  on  the 
application.  Currently  both  PC’s  have  4  IP  modules  consisting  of  a  serial  communication 
(IP  Serial)  module,  digital-to-analog  (IP  DAC)  module,  analog-to-digital  (IP  HiADC) 
module,  and  a  pulse  width  modulation  (IP  68332)  module.  A  description  of  each  IP 
module  and  procedures  for  connecting  hardware  to  the  model  is  covered  in  detail  in  the 
Hardware-In-The-Loop  Testing  section  of  this  thesis. 

B.  XMATH/SYSTEMBUILD 

Xmath/SystemBuild  is  a  software  program  similar  to  the  Matlab/Simulink 
software  programs.  Xmath  is  the  parent  process  and  will  launch  the  SystemBuild  editor 
when  the  build  command  is  given  or  when  a  file  is  loaded  that  contains  SystemBuild 
data.  It  was  designed  to  include  an  extensive  set  of  design  and  analysis  functions  for  both 
the  classical  input/output  control  techniques  and  the  modem  state-space  control 
techniques.  The  SystemBuild  program  uses  a  hierarchical  method  of  organization,  based 
on  the  SuperBlock  concept.  SuperBlocks  provide  a  way  of  organizing  a  group  of  blocks 
that  define  a  function  into  a  compact  form  for  display.  Through  the  use  of  this  hierarchy, 
variable  names  can  be  passed  up  and  down  the  hierarchical  structure  allowing  the 
engineer  to  easily  track  and  understand  what  variables  are  and  where  they  interact  with 
the  model.  This  section  will  cover  the  basic  functions  of  Xmath/SystemBuild,  for 
detailed  information  refer  to  [Ref.  4], 

1.  Xmath  Basics 

Xmath  can  be  run  from  either  the  SUN  or  SGI  workstations  located  in  the 
avionics  and  aeronautics  labs.  Prior  to  using  the  MATRIXx  software,  the  user  must 
configure  his  UNIX  account  to  source  the  ‘aclOOsetup’  file  which  defines  the  editor  used 
by  the  system.  This  command  should  be  set  up  as  a  marcro  in  the  user’s  .cshrc  file  so  it 
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will  automatically  run  each  time  the  user  logs  on  to  the  workstation.  Adding  the 
following  command  line  to  the  .cshrc  file:  ‘source$ISI/AC100/bin/acl00setup.sh’,  will 
accomplish  this. 

Before  invoking  Xmath,  a  separate  directory  for  each  project  should  be  created  to 
avoid  using  project  files  from  one  project  with  the  standard  files  of  another  project. 
Therefore,  start  by  first  creating  a  project  directory  and  then  move  to  that  new  directory 
using  the  following  UNIX  commands:  mkdir  projectname,  cd  projectname.  To  start 
Xmath  type  «  xmath  »  in  the  console  window.  This  will  bring  up  the  Xmath 
command  window  as  shown  in  Figure  3.3. 


Figure  3.3:  Xmath  Command  Window 
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2.  SystemBuild  Modeling 

This  section  is  a  tutorial  that  covers  the  basics  of  the  SystemBuild  editor  and 
simulator.  In  the  following  example,  the  user  will  build  a  block  diagram  and  simulate  its 
operation.  The  model  for  this  illustration  is  a  simple  Speed  Controller  shown  below  in 
Figure  3.4. 


Step  1:  Defining  the  SuperBlock 

To  invoke  SystemBuild,  at  the  Xmath  command  line  type  «  build  »  and  press 
return.  The  SystemBuild  menu  bar  will  appear  across  the  top  of  the  display.  Select 
Build  from  the  menu  bar  with  the  left  mouse  button.  Then  select  Edit  SuperBlock  from 
the  Build  menu.  The  Edit  SuperBlock  dialog  box  will  appear  and  initially  the  menu  in 
the  box  is  empty.  Click  the  left  mouse  button  on  Edit  New  SuperBlock,  and  the 
SuperBlock  Attributes  dialog  box  appears.  Using  the  SuperBlock  Name  field,  name  the 
SuperBlock.  Under  Type,  select  Continuous  and  click  DONE. 

Step  2:  Placing  the  Blocks 

A  new  SystemBuild  editor  window  should  be  displayed,  ready  for  building  the 
block  diagram.  To  select  from  the  SystemBuild  block  library,  click  on  Define  Block 
from  the  Edit  menu  or,  using  a  shortcut,  double-click  in  the  empty  window  to  bring  up 
the  SystemBuild  block  menu.  The  SystemBuild  blocks  are  grouped  together  in  thirteen 
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palettes.  To  select  a  palette,  click  on  one  of  the  three-letter  combinations  at  the  top  of  the 
menu. 

To  begin  building  the  SpeedController,  first  select  the  Gain  Block  from  the 
algebraic  block  palette  (ALG).  Click  and  hold  the  left  mouse  button  on  this  block,  drag  it 
into  the  screen,  and  release  the  mouse  button  when  the  Gain  block  dialog  box  appears, 
name  the  block,  if  desired,  and  click  DONE.  Next,  select  the  Summer  block  from  the 
AGL  palette  and  the  Inegrator  block  from  the  DYN  palette  using  the  same  procedures. 

Step  3:  Connecting  the  Blocks 

The  next  step  is  to  connect  the  blocks.  Note  the  middle  mouse  button  will  be  used 
to  make  connections.  Start  by  connecting  the  Summer  block  with  the  Integrator  block. 
Click  in  the  Summer  block,  with  the  middle  mouse  button,  then  click  on  the  Integrator 
block.  A  line  should  connect  the  two  blocks.  Using  the  same  procedure,  connect  the 
Integrator  to  the  Gain  block.  Now,  connect  the  Gain  block  to  the  Summer  block.  Since 
there  is  more  than  one  input  to  the  Summer,  the  Connection  Editor  will  appear  as  shown 
in  Figure  3.5.  Use  the  connection  editor  to  specify  the  connections;  the  inputs  to  a  block 


Franco  : 


Cancel 


Add 


Del 


Dane 


Figure  3.5:  Connection  Editor 
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are  in  numerical  order  from  top  to  bottom.  The  output  from  the  Gain  block  should  go  to 
the  second  input  of  the  Summer.  Then  with  the  left  mouse  button’  connect  to  Gain  block 
with  the  number  2  Summer  input,  highlight  Add  and  click  Done. 

Note  that  the  blocks  can  be  resized  by  clicking  on  the  block  id  number  and 
moving  the  mouse,  or  flipped  by  double-clicking  on  the  block’s  body. 

Step  4:  Connecting  External  Inputs  and  Outputs 

Input  connections:  click  the  middle  mouse  button  in  the  open  space,  then  in  the 
Summer  block.  The  connection  editor  dialog  box  appears.  With  the  left  mouse  button, 
click  the  number  1  port  of  the  Summer  block  then  click  Done.  To  label  the  external 
input,  click  and  hold  the  left  mouse  button  in  the  SuperBlock  ID  bar,  just  above  the 
SystemBuild  window.  Select  SuperBlock  Attributes.  In  the  dialog  box,  select  the  Labels 
tab  and  under  Input  Naming  select  Enter  Local  Label  Names.  Now  select  the  Input 
tab  and  beside  Input  Label  type  the  desired  name.  Click  Done. 

Output  connections:  With  the  middle  mouse  button  click  in  the  integrator  block, 
then  click  in  an  open  space.  Connect  the  two  boxes,  then  click  Done. 

Simulating  the  Model 

The  Speed  Control  model  can  now  be  simulated.  There  are  a  number  of  different 
methods  to  simulate  model,  two  of  which  are  described  here; 

Method  1:  First  define  a  time- vector  in  Xmath  by  specifing  a  name,  range,  and 
an  increment.  In  the  Xmath  command  window  type:  «  t=[0  :  .1  :  20]’  »;.  Next, 
specify  an  input  vector  of  magnitude  one:  «  u=ones(t)  »;.  Enter  the  simulation 
command.  Type:  «  y—sim(“  Name  of  SuperBlock” ,  t ,  u)  »;.  Note  in  this  example  the 
name  of  the  SuperBlock  is  Speed  Contr oiler .  This  command  invokes  the  simulator, 
specifies  that  the  Speed_Controller  model  SuperBlock  is  to  be  processed,  and  sets  the 
output  equal  to  y.  After  the  simulation  is  complete,  plot  the  output  by  typing:  «  plot(y) 
».  Note,  more  details  on  using  the  sim  command  are  available  by  typing  «  help  sim  » 
in  the  Xmath  command  window. 
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Method  2:  From  the  menu  bar  under  analysis  select  Simulation.  This  will  bring 
up  the  simulation  parameter  dialog  box.  Define  a  time  vector  and  input  vector  as  above 
and  run. 

Analyzing  the  Model 

The  Xmath/SystemBuild  software  contains  an  extensive  set  of  functions  for 
system  analysis.  Specifics  for  analyzing  the  model  can  be  found  in  the  Xmath  and 
SystemBuild  Core  Manuals  located  in  the  avionics  lab  or  by  using  the  help  command. 

To  linearize  the  model,  the  Xmath  command  is  «  sys=lin("  Super  Block 
name",  {keywords})  »,  where  sys  is  the  name  of  the  Xmath  system  object  in  state-space 
form.  Other  useful  commands  include:  poles(sys),  eig(a),  bode  (sys). 

Saving  the  Model 

To  save  the  model  select  File  from  the  menu  bar,  highlight  the  SuperBlock  name 
and  click  on  Save. 


C.  REALSIM  SERIES  RAPID  PROTOTYPING 

This  section  will  continue  with  the  design  of  the  speed  controller  presented  in  the 
last  section.  The  tutorial  will  demonstrate  the  basic  procedures  for  using  the  GUI  and 
testing  on  a  real-time  controller.  Later  sections  will  describe  how  the  hardware  is 
connected  to  the  model  and  the  procedures  for  hardware-in-the-loop  testing. 

1.  RealSim  Graphical  User  Interface  (GUI) 

Each  RealSim  project  is  placed  in  a  unique  RealSim  project  directory.  A  number 
of  standard  files  are  associated  with  each  RealSim  project.  Therefore  it  is  recommended 
to  create  a  separate  project  directory  for  each  project.  The  project  name  and  the  directory 
name  should  be  the  same. 
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To  invoke  the  RealSim  GUI  type  «  realsim  »  in  the  UNIX  command  window. 
When  the  RealSim  GUI  is  invoked  in  a  new  directory  a  dialog  box  will  appear  along  with 
the  GUI.  Pressing  return  or  clicking  yes  in  the  dialog  box  will  enable  the  makeproject 
command  which  creates  the  first  of  the  required  standard  files  called  animation 
configuration  file  (animation.cfg).  Once  all  the  default  settings  have  been  accepted,  the 
project  name  in  the  bottom  left-hand  comer  of  the  GUI  should  be  listed. 

Next  the  user  must  create  a  target  configuration  file  (targetconfig.cfg)  file.  This 
file  contains  information  such  as  the  settings  that  the  AutoCode  needs  to  generate  the 
appropriate  C  code,  which  controller  the  model  is  to  run,  how  many  processors  are  in  the 
controller.  This  file  will  be  used  later  to  compile,  link,  download  and  run  the  design.  To 
create  this  file,  click  on  show  utilities  in  the  GUI  and  select  Retarget.  The  target  is  the 
node  name  of  the  controller.  In  the  UNIX  command  window  the  user  will  be  asked  for 
the  ‘controller  host  name[  ]:’  which  in  the  avionics  lab  is  ‘ america .  ’  All  of  the  remaining 
default  settings  should  be  accepted.  After  retargeting  the  system  to  ‘ america ’  the  GUI 
should  indicate  this  in  the  middle  of  the  bottom  line  in  the  GUI,  see  Figure  3.6. 

These  files  are  only  created  once  for  each  project,  as  long  as  there  are  no  changes 
to  the  system  configuration.  Once  these  standard  files  have  been  set  up  for  a  specific 
project,  and  the  user  is  in  the  project  directory  for  that  project,  typing  «  realsim  »  in 
the  UNIX  command  window  will  start  the  GUI  targeted  accordingly. 

Through  the  use  of  the  GUI  the  designer  can  now  follow  the  flow  diagram  that 
steps  the  user  through  the  design  process.  As  the  user  performs  each  step  of  the  process, 
the  GUI  paths  are  filled  in,  indicating  the  current  stage  in  the  design  process.  If  certain 
RealSim  files  are  older  than  their  logical  predecessors,  the  Needs  Up  dating  indicator  will 
be  displayed. 


2.  Building  the  Model 

The  first  step  in  the  process  is  building  the  model  using  Xmath/SystemBuild,  as 
described  in  the  previous  section.  To  continue  with  the  speed  controller  model,  click  on 
the  Xmath/SystemBuild  block  in  the  GUI.  This  will  bring  up  the  Xmath  command 
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window.  From  this  window,  select  file  and  load  from  the  menu  bar.  Highlight  the  file 
name  and  click  OK.  Select  the  SuperBlock  from  the  build  menu  to  display  the  model  of 
the  Speed_Controller. 


The  Project  is  The  Target  is  A1  is  the  target 

the  name  of  the  the  node  name  of  configuration  of 

project  you  are  the  controller.  application 

currently  running.  processor  #  1 . 

Figure  3.6:  RealSim  Graphical  User  Interface 

The  SuperBlock  design,  for  this  example,  is  presently  a  continuous  type  and  needs 
to  be  transformed  to  a  discrete  controller  (z-domain).  Selecting  Transform  SuperBlock 
under  Build  from  the  menu  bar  will  display  the  transform  dialog  box.  Highlight  the 
SuperBlock  name  and  under  type  select  Discrete,  then  click  Transform.  When 
transforming  from  continuous-time  to  discrete-time  a  time  delay  block  must  be  added  to 
the  block  diagram,  as  shown  in  Figure  3.7.  From  the  DYN  palette  select  the  time  delay 
block. 
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Figure  3.7  :  Discrete  SuperBlock  for  Speed  Controller 

3.  AutoCode 

Once  the  SuperBlock  is  complete,  the  user  must  generate  real-time  code.  In 
SystemBuild,  select  Generate  Real-Time  Code  from  the  Build  pull-down  menu.  When 
the  dialog  box  appears,  highlight  the  SuperBlock  for  which  you  want  to  generate  code. 
Beside  the  generated  code  language,  select  RTF  only,  and  check  that  the  filename  is  the 
same  as  the  project  name,  then  click  DONE.  This  produces  a  file  with  the  model  name 
followed  by  a  .rtf  extension.  This  file  containing  the  real-time  code  is  a  top  level 
input/output  code  that  is  used  by  the  AutoCode  program  to  produce  a  higher-level 
language  used  to  conduct  hardware-in-the-loop  testing. 

After  the  user  has  generated  a  real-time  file  from  the  SystemBuild  model, 
invoke  the  AutoCode  by  clicking  the  AutoCode  button  in  the  RealSim  GUI.  The 
AutoCode  high-level  language  code  generator  reads  the  real-time  (or  .rtf)  file  and 
produces  a  high-level  source  code  file  with  the  extension  of  .c.  This  file  will  be  used  to 
compile,  link,  and  run  the  design.  The  GUI  should  now  indicate  the  completion  of  the 
AutoCode  process. 
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4.  Interactive  Animation 


The  next  step  is  to  build  the  Interactive  Animation  (IA)  picture  display  for 
monitoring  and  controlling  the  model  while  it  is  being  executed  in  the  workstation 
simulation  environment  or  during  hardware-in-the-loop  testing.  Invoke  the  editor  by 
clicking  on  the  Interactive  Animation  Builder  button  in  the  GUI.  The  animation  diagram 
is  made  by  selecting  icons  from  a  given  library  of  gauges,  dials,  switches,  and  other 
various  input  and  output  devices.  The  Interactive  Animation  section  of  the  AC  100  User’s 
Guide  [Ref.  4]  has  details  on  all  of  the  available  icons.  Selecting  DEFINE  from  the  IA 
control  panel  will  display  the  library  of  icons.  For  the  Speed  Controller  example  select 
the  dial  for  the  input  and  a  digital  readout  for  the  output  as  shown  in  Figure  3.8.  The 
RTF  NAMES  button  in  the  control  panel  loads  the  I/O  names  from  the  model  .rtf  file  and 
must  be  loaded  prior  to  making  any  connections.  Using  the  IA  Connection  editor, 
similar  to  the  SystemBuild  editor,  the  appropriate  inputs  and  outputs  are  connected  to  the 
appropriate  devices.  Once  the  picture  is  complete  select  SAVE  PICT  from  the  control 
panel  and  a  file  with  a  .pic  extension  is  created  in  the  working  directory. 


Speed_Controller 


V©  loc i ty_Xnput 
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Figure  3.8:  IA  Speed_ControIler 


5.  Hardware  Connection  Editor  (HCE) 

The  Hardware  Connection  Editor  is  used  to  make  connections  from  the  external 
I/O  in  the  SystemBuild  model  to  either  external  hardware  I/O  devices  for  hardware-in- 
the-loop  testing  or  to  the  IA  module  for  simulation.  Before  invoking  the  HCE,  the  user 
should  have  a  copy  of  the  file  lc_c30.hce’  in  the  project  directory.  This  file  informs  the 
HCE  what  type  of  external  I/O  devices  the  target  computer,  America,  is  equipped  with. 
This  process  will  be  covered  in  greater  detail,  along  with  the  current  set-up  in  the  avionics 
lab,  in  the  Hardware-In-The-Loop  Testing  section  of  this  thesis. 

Two  connection  editors  will  appear  when  starting  the  HCE.  The  first  screen  is  for 
the  SuperBlock  external  inputs  and  the  second  for  external  outputs  (see  Figure  3.9).  For 
this  example,  the  input  device  will  be  ‘MONITOR_INPUT’  type.  No  changes  should  be 
required  to  the  editors  and  the  only  action  by  the  user  should  be  to  click  DONE  to  both 
pages. 
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Use  left  nouse  button,  tab,  shift-tab,  or  return  to  select  item. 
Use  middle  mouse  button  on  toggle  items  for  pull-down  menu's. 
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Figure  3.9:  HCE 
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6.  Compile  and  Link 

Once  the  AutoCode  is  complete  the  C  source  files  need  to  be  compiled  and  linked 
to  the  C30.  Selecting  the  Compile  and  Link  button  in  the  RealSim  GUI  will  cause  the 
UNIX  systems  to  connect  via  ftp  with  the  AC  100  target  computer  {America).  For  this  to 
happen  the  host  computer,  America,  must  be  in  the  ftp  mode.  Typing  ‘aclOOsvr’  at  the 
DOS  prompt  on  America  will  enable  the  computer  for  ftp  transfer.  The  compiler 
generates  object  code  from  the  .c  file  and  the  link  creates  a  C30  DSP  executable  from  the 
object  code. 

7.  Download  and  Run 

When  all  the  above  steps  are  completed,  the  model  is  ready  to  be  tested.  The 
testing  for  this  illustration  will  be  a  simulation  only,  since  no  hardware  is  connected. 
Selecting  Download  and  Run  on  the  GUI  will  connect  the  RealSim  software  to  the  target 
AC  100  computer  through  ftp.  Once  the  connection  is  made,  it  will  automatically  load  the 
C30  executable  into  the  C30  memory  and  prepare  it  to  run.  The  IA  module  will  appear 
on  the  workstation  window  along  with  a  control  panel  called  IA  Client,  see  Figure  3.10. 

The  START  CONTROLLER  button  starts  the  execution  of  the  model  using  the 
initial  values  loaded  from  the  projectjiame.ioc  file  for  the  external  inputs,  and  outputs 
defined  by  the  SystemBuild  model.  The  STOP  CONTROLLER  button  stops  the 
executing  application  and  holds  the  external  inputs  and  outputs  at  their  final  values.  The 
RESTART  CONTOLLER  button  restarts  the  model,  again  using  the  initial  values  that 
were  loaded  from  the  project  name,  ioc  file. 

The  HARDWARE  RESET  button  causes  the  RealSim  controller  to  perform  a 
hardware  reset  and  causes  the  IA  Client  to  exit.  This  is  the  best  way  to  exit  after  a  run,  as 
it  will  clear  the  C30  memory  and  return  the  AC  100  computer  to  a  ready  status.  The  third 
button,  EXIT  GRAPHICS,  exits  the  IA  Client  without  rebooting  the  controller.  This  is  a 
software  reboot  only,  which  stops  the  model  and  terminates  the  ftp  connection.  This 
button  is  not  recommended  for  use,  as  it  will  not  stop  the  model  from  running  on  C30. 
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Figure  3.10:  IA  Client 


8.  Data  Acquisition  Editor 

The  RealSim  data  acquisition  editor  defines  one  or  more  data  acquisition  sets  for 
each  project  and  provides  real-time  data  acquisition.  This  allows  the  user  to  record  and 
analyze  any  of  the  inputs  or  outputs  associated  with  the  project.  To  invoke  the  data 
acquisition  editor  select  ‘Data  Acq.  Editor’  from  the  show  utilities  button  in  the  GUI. 
The  first  data  acquisition  screen  to  appear  contains  all  the  inputs  to  the  system.  The  user 
selects  the  desire  inputs  for  recording  by  highlighting  the  variable  and  selecting  ‘ON’ 
next  to  the  DA_Setting  modifier  field  at  the  bottom  left  of  the  screen.  The 
‘DAJDecimationFactor’  should  read  ‘1’,  this  ensures  the  value  will  be  recorded  every 
time  step.  To  select  the  outputs  for  recording,  toggle  the  ‘Display’  selector  at  the  bottom 
of  the  screen  from  the  ‘SB  INPUTS’  to  ‘SB  OUTPUTS’. 

The  START  DATA  ACQUISITION  button  starts/stops  the  data  acquisition 
program  which  will  record  any  or  all  of  the  inputs  and  outputs  to  the  C30.  Starting  the 
data  acquisition  creates  a  file  in  the  project  directory  with  the  project  name  and  ‘_l.raw’ 
extension.  Each  time  the  acquisition  process  is  started  a  new  file  is  created  and  the 
number  will  increment  up  corresponding  to  the  number  of  data  files  created.  Therefore  it 
is  good  practice  to  note  which  data  files  correspond  to  which  runs  when  testing. 

To  retrieve  the  data  after  the  exiting  the  controller,  the  user  selects  ‘Convert  DA 
Data’  from  the  show  utilities  button  in  the  GUI.  The  workstation  command  window  will 
show  the  last  data  file  recorded  with  a  ‘.dat’  file  extension.  The  user  can  accept  the  file 
listed  in  the  window  by  pressing  return  or  select  a  previous  file  by  changing  the  number 
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of  the  file.  This  process  creates  a  file  with  the  same  name  as  the  corresponding  raw  file 
that  can  now  be  loaded  directly  into  Xmath  for  analysis.  The  variable  names  will  be  the 
same  as  those  used  as  the  input  or  output  names  in  the  SystemBuild  model.  These 
variables  will  be  vectors  with  lengths  depending  on  the  amount  of  time  that  data  was 
recorded.  A  reference  file  is  also  created  when  converting  the  data  that  contains  specific 
information  on  that  data  file,  such  as  the  amount  of  time  recorded  or  the  number  of 
elements  in  the  file.  This  will  help  identify  data  files  if  numerous  runs  are  made  during 
testing. 
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IV.  HARDWARE-IN-THE-LOOP  (HITL) 


This  section  outlines  the  process  of  connecting  hardware  to  a  digital  controller. 
By  using  the  standard  input/output  devices  integrated  with  the  RealSim  software,  the 
SystemBuild  diagram  is  connected  to  the  desired  hardware.  A  critical  part  of  connecting 
hardware  to  the  controller  is  the  calibration  of  the  sensors.  The  controller  uses  an 
algebraic  conversion  of  the  measured  sensor  output  signal  from  the  hardware.  This 
algebraic  conversion  requires  calibration  by  determining  the  correct  conversion  constants. 

To  demonstrate  this  step  of  the  design  process  in  the  avionics  lab,  a  device  called 
the  Airborne  Remotely  Operated  Device,  AROD,  will  be  used.  The  lab  currently  has  two 
AROD  devices  which  the  students  will  use  for  calibration  and  HITL  testing.  A  complete 
description  of  the  AROD  is  given  in  [Ref.  5]. 

A.  HARDWARE  DESCRIPTION  FOR  AROD 

The  control  surfaces  of  the  AROD  are  actuated  by  Futaba  FP  S34  servo  motors. 
To  control  these  actuators,  a  Pulse  Width  Modulation  (PWM)  input  signal  is  used.  The 
width  of  the  pulse  determines  how  far  the  servo  will  turn.  The  internal  control  circuit  of 
the  Futaba  motor  includes  a  small  potentiometer  in  a  feedback  loop  to  sense  the  servo 
position.  The  output  signal  from  this  sensor  is  noisy  due  to  the  varying  current  draw 
during  motor  operation.  Therefore,  the  actuators  installed  on  the  AROD  in  the  lab  have 
been  modified  to  reduce  sensor  noise.  An  additional  wire  has  been  added  so  that  the 
positive  voltage  on  the  potentiometer  could  be  measured  at  the  same  time  as  the  center 
voltage  [Ref.  5],  Taking  the  difference  between  the  measured  high  voltage  VH  and  the 
centered  voltage  Vq  ,  give  a  delta  voltage  Fb  and  results  in  a  significant  reduction  in 
sensor  noise.  This  set  up  is  shown  in  Figure  4.1. 
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Figure  4.1:  Futaba  Actuator 
B.  CONVERSION  SUPERBLOCKS 

For  this  design,  the  controller  input  commands  are  given  in  degrees.  Since  the 
input  signal  to  the  actuators  operates  on  PWM,  a  conversion  from  degrees  to  PWM  must 
first  be  implemented.  Similarly,  the  output  signal  from  the  sensors  must  be  converted 
from  volts  to  degrees.  Figure  4.2  shows  the  SuperBlocks  that  will  be  developed  to 
implement  this  design. 


Figure  4.2:  Conversion  SuperBlocks 


1.  Converting  Degrees  to  PWM 

Previous  testing  of  the  actuators  has  determined  the  total  throw  to  be  0  to  200 
degrees,  with  a  pulse  width  of  0.6  milli-seconds  corresponding  to  the  minimum 
deflection,  2.4  milli-seconds  corresponding  to  the 'maximum  deflection,  and  a  pulse- 
width  of  1.5  milli-seconds  corresponds  to  the  centered  position,  [Ref.  5]. 
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The  refresh  frequency  for  the  AROD  HITL  test  was  chosen  to  equal  the  controller 
frequency  of  25  Hertz,  giving  a  period  T  of  40  milli-seconds.  Figure  4.3  depicts  the 
relevant  quantities  for  a  PWM  signal. 
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Figure  4.3:  PWM 


Duty  cycle  is  calculated  as: 

Duty  Cycle  — 

A  minimum  pulse  width  of  0.6  milli-seconds,  corresponding  to  -100  degrees,  results  in  a 
duty  cycle  of: 

Min.  Duty  Cycle  (-100  deg.)  =  ~  =  0.015 

The  maximum  pulse  width  of  2.4  milli-seconds,  corresponding  to  +100  degrees,  results  in 
a  duty  cycle  of: 

2.4 

Max.  Duty  Cycle  (+100  deg.)  =  —  =  0.06 

Assuming  a  linear  relationship  from  minimum  to  maximum  values,  the  following 
function  is  used  to  determine  the  required  duty  cycle  for  a  given  input  in  degrees. 

Duty  Cycle  =  0.0002  *  (Desired  deflection  in  degrees)  +  0.0375  (Eq.  4.1) 

The  algebraic  block  ‘ Deg_2_PWM ’  shown  in  Figure  4.4  implements  this  equation. 
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Figure  4.4:  Deg_2_PWM  SuperBlock 
2.  Converting  Volts  to  Degrees 

The  output  signal  from  sensors  on  the  AROD,  as  described  above,  is  the 
difference  between  the  measured  high  voltage  VH  and  the  centered  voltage  Vc.  This 
voltage  signal  must  be  converted  to  the  correct  vane  position  in  degrees  for  feedback  to 
the  RealSim  controller  and  user  display.  Again  it  is  assumed  that  there  is  a  linear 
relationship  from  minimum  to  maximum  deflection  as  shown  in  Figure  4.5. 


Figure  4.5:  Volts  to  Degrees  Conversion 

Therefore  the  measured  output  voltage  from  the  sensor  can  be  converted  into  correct  vane 
position  in  degrees  by: 
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Degout : 


200 


V  -V 

y  pi  00  v  ml  00 


(VD-V0) 


(Eq.  4.2) 


The  algebraic  block  4  Volts _2_Deg’  shown  in  Figure  4.6  implements  this  equation. 


Figure  4.6:  Volts_2_Deg  SuperBlock 

C.  SENSOR  CALIBRATION 

Before  the  sensors  can  be  used  reliably  by  the  controller,  they  must  be  calibrated. 
Due  to  small  changes  in  the  operating  voltages,  calibration  is  required  each  time  the 
controller  is  started.  The  calibration  process  illustrated  here  for  the  AROD  involves 
measuring  the  sensed  voltages  for  vane  positions  of  maximum  deflection  (-100  deg), 
minimum  deflection  (+100  deg),  and  the  centered  position  (0  deg.).  These  measured 
voltage  values  are  then  used  in  Equation  4.2  to  obtain  the  correct  vane  position. 
Referring  to  the  Calibration  IA  screen  shown  in  Figure  4.7,  the  calibration  procedures 
are: 

•  Command  zero  degrees  of  deflection  using  the  ‘Deg  cmd’  dial.  Input  the 
displayed  voltage  into  the  window  labeled  ‘V0’. 

•  Repeat  step  1  for  max.  (+100  deg.)  deflection  and  min.  (-100)  deflection. 

•  Confirm  that  the  degrees  sensed  are  the  same  as  the  commanded  degrees. 
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Figure  4.7:  Calibration  I A  Screen 

D.  INPUT/OUTPUT  CONNECTIONS 

The  I/O  configuration  for  AC100  and  America  are  given  in  Table  I.  The  module 
numbers  given  in  Table  II  are  entered  by  the  user  to  the  hardware  connection  editor  to 
define  the  type  of  I/O  device  required. 


Table  I:  I/O  Configuration 


Module 

America 

AC100 

IPSerial 

3 

1&3 

IPHiADC 

1 

IP_DAC 

2 

2 

IP68322 

4 

4 
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As  an  example,  the  HITL  design  project  requires  an  IP  68322  I/O  module  for  the 
PWM  connection  from  the  C30  to  the  AROD.  The  voltage  signal  from  the  AROD  to  the 
C30  uses  the  IP  HiADC  module.  Appendix  A  includes  the  HCE  input  and  output 
screens  for  this  project. 

A  brief  description  is  given  below  for  the  I/O  modules  used  in  the  avionics  lab. 
References  are  also  provided  which  contain  more  specific  details  on  each  module  and 
procedures  for  making  the  required  connections. 


1.  Serial  Connections/  IPJSerial  Module 

The  IP  Serial  module  provides  two  channels  of  high  performance  multi-mode 
serial  communication,  [Ref.  6]  section  5  page  69.  Both  RS-232-C  and  RS-422  are  fully 
supported.  The  module  can  be  programmed  to  baud  rates  of  2  Mbit/sec  and 
asynchronous  or  synchronous  protocols. 


2.  Analog-to-Digital  Connections/IP_HiADC 

The  Hi  ADC  provides  16  input  analog  channels  with  12-bit  resolution  and 
synchronous  sampling  of  all  inputs,  [Ref.  6  ]  section  5  page  61.  The  module  can  convert 
one  analog  channel  in  1.2  /usee  or  approximately  800  K  samples/second.  Each  channel 
has  a  fixed  voltage  range  of  +  5  V.  No  anti-aliasing  filtering  is  provided  for  by  the 
module  so  inputs  should  be  band-limited  to  Vi  the  sampling  frequency  of  the  system. 


3.  Digital-to-Analog  Connections/IP_DAC 

The  DAC  module  provides  six  channels  of  12-bit  digital-to-analog  conversion. 
Each  channel  can  be  configured  to  either  +  5V  or  0-1 0V  output  ranges,  [Ref.  6]  section  5 
page  34. 
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4.  Pulse  Width  Modulation  Connections/IP_68332 

The  IP68332  module  is  a  time  processing  unit  (TPU)  that  can  perform  one  or 
more  hardware  I/O  functions,  [Ref.  6]  section  5  page  52.  It  can  be  programmed  to 
generate  various  digital  I/O  signals,  the  current  set-up  in  the  avionics  lab  will  use  Pulse 
Width  Modulation  (PWM)  signals.  In  the  PWM  mode,  the  user  specifies  the  duty  cycle 
as  the  output  from  the  SystemBuild  diagram. 
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V.  DIGITAL  CONTROL  DESIGN 


The  RealSim  rapid  prototyping  series  allows  for  control  system  to  be  tested  in 
real-time  with  hardware-in-the-loop  while  recording  any  or  all  the  state  variables  to 
verify  performance.  This  section  will  step  through  the  design  process  using  a  simple 
controller  to  control  the  control  surfaces  of  the  FROG. 

A.  MODELING  ACTUATORS  AND  SENSORS 

Before  the  controller  can  be  designed,  a  mathematical  model  of  the  plant  which  is 
to  be  controlled  must  first  be  created.  The  techniques  involved  to  develop  the  model 
depend  on  the  characteristics  of  the  plant.  This  section  details  the  technique  used  to 
model  the  actuators  used  on  the  FROG.  Since  both  the  FROG  and  AROD’s  control 
surfaces  are  actuated  by  Futaba  FP  S34  servo  motors,  the  AROD  is  used  in  the  lab. 

To  develop  an  accurate  representation  of  the  Futaba  actuators,  the  system  is 
modeled  as  a  second-order  transfer  function. 


H(s)  = 


CO.. 


+  2< 


(0,,-s  +  co; 


The  system  response  is  obtained  by  applying  a  step  function  to  the  actuators  and 
recording  the  response  using  the  data  acquisition  editor  feature  of  the  RealSim  software. 
To  calculate  the  transfer  function,  the  rise  time  tr  and  maximum  overshot  Mp  values  are 
measured  from  the  system  response.  From  these  values  the  natural  frequency  con  and  the 
damping  ratio  C,  are  calculated  using  the  following  formulae: 


<r= 


In (Mp) 


(Eq.  5.1) 
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(jnL) 


-tan 

®„  = - r= - -  (Eq.  5.2) 

VWH 

It  is  assumed  the  actuators  have  a  rate-limiter  therefore  a  small  step  response  of 
10  degrees  is  used  so  the  effect  of  the  rate-limiter  on  the  rise  time  would  be  minimized. 
Then  a  larger  step  of  100  degrees  is  given  to  estimate  the  rate  limits  of  the  actuator.  The 
results  are  plotted  and  shown  in  Figure  5.1  and  5.2.  Note,  to  obtain  a  clearer  picture  of  the 
actuators  step  response  for  the  10  degree  step,  the  signal  was  fed  through  a  lowpass  filter 
with  a  cut-off  frequency  of  10  hertz. 

From  the  10  degree  step  response  plot,  values  for  the  maximum  overshoot  Mp 
and  rise  time  tr  were  measured  as: 

Mp-  2  tr  =  .06, 

From  equations  5.1  and  5.2,  the  con  and  C,  were  calculated  as: 

con  =  20.55  £=  .455, 


Figure  5.1:  Step  Response  of  Futaba  Actuator  (10  deg.) 
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Figure  5.2:  Step  Response  of  Futaba  Actuator  (100  deg.) 

The  slope  of  the  100  degree  step  response  is  measured  and  used  to  calculate  the 
rate-limiter,  which  was  found  to  be  approximately  +325  deg./sec. 

The  2nd  order  transfer  function  can  be  given  in  general  form  by: 


m= 


axs  1  +  a2s  2 
1  +  b,s~l  +  b2s~ 2  ’ 


where 


a,  =  0 


a,  =  co„ 


bx  =2-£-o)n 
b2=o)n2 


This  transfer  function  was  then  implemented  in  SystemBuild,  see  Figure  5.3.  Computer 
simulations  were  run  on  the  model  and  the  step  response  recorded  and  plotted  along  side 
the  actuator’s  step  response  for  analysis.  By  changing  the  damping  ratio  and  natural 
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frequency  of  the  transfer  function,  the  step  response  of  the  model  was  made  to  match  the 
response  of  the  actuator.  The  final  values  for  the  damping  ratio  and  the  natural  frequency 
were: 

C=55 
a>„  =  25 

The  step  responses  of  the  final  second-order  model  and  the  actuator  are  shown  in 
Figure  5.4. 


Figure  5.3:  Second  Order  Actuator  Model 


Figure  5.4:  Step  Response  of  Actuator  and  Second-Order  Model 
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B.  FEEDBACK  CONTROLLER  DESIGN 


The  next  step  is  to  design  a  feedback  controller  that  satisfies  specific 
requirements.  The  requirements  are  normally  specified  in  terms  of  response  time, 
overshoot,  stability  and  robustness.  The  controller  design  process  is  outlined  below: 

•  Create  a  nonlinear  model.  A  block  diagram  is  formed  that  includes  the  plant 
model  and  nonlinear  controller. 

•  Linearize  the  model  and  adjust  controller  gains.  The  linear  model  is 
linearized  and  then  analyzed  using  frequency  response  and/or  root-locus 
methods. 

•  Analyze  closed-loop  system.  Computer  simulations  are  run  with  the  feedback 
system,  the  controller  gains  are  adjusted  to  create  the  desired  control. 

Applying  classical  control  techniques,  the  controller  model  is  generally  first 
designed  in  continuous-time.  After  a  satisfactory  response  is  achieved  the  system  is 
transform  to  discrete-time  and  tested  again  for  satisfactory  response. 

For  this  example  the  Speed_Controller  developed  in  Chapter  III  is  implemented 
with  the  actuator  model.  To  analysis  the  system  the  loop  between  the  controller  and  plant 
is  broken  as  shown  in  Figure  5.5.  The  system  is  linearized  using  the  Xmath  command 
sys=lin(“ Super Block  name”).  The  linearized  model  can  be  used  to  analyze  the  system 
using  root-locus  methods  and  Bode  frequency  response  methods.  The  root-locus  and 
Bode  plots,  shown  in  Figure  5.6,  are  generated  using  the  Xmath  commands:  rlocus(sys) 
and  bode(sys).  After  a  satisfactory  response  is  obtained,  the  system  is  transformed  to 
discrete-time  and  tested  again. 
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C.  HARDWARE-IN-THE-LOOP  TESTING 


Hardware-in-the-loop  testing  is  where  the  feedback  system  is  tested  with  some  or 
all  of  the  actual  hardware.  In  this  case,  the  design  will  include  the  actuator,  the  actuator 
model  and  the  SpeedController,  as  shown  in  Figure  5.7.  This  design  allows  the 
controller  to  be  simulated  with  the  actuator  model  or  conduct  HITL  testing.  If  the 
actuator  model  is  accurate  and  the  controller  design  is  correct,  there  should  be  no 
apparent  difference  in  the  performance  of  the  controller.  If  the  actuators  are  not  modeled 
well,  the  test  of  the  controller  may  indicate  that  the  controller  works  as  designed  while 
the  HITL  test  may  show  that  the  feedback  system  is  unstable. 


14 


Figure  5.7:  HITL  Test  SystemBuild  Block  Diagram 

The  simulation  includes  two  switches  for  controlling  the  desired  simulation  state. 
The  three  simulation  states  are: 

•  Sensor  calibration 

•  Actuator  model 

•  HITL 

The  calibration  switch  controls  which  input  command  will  be  used  by  the 
actuators.  With  the  calibration  switch  On ,  the  command  input  Deg_cmd  is  used.  When 
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the  switch  is  Off  the  commanded  input  is  from  the  error  signal  of  the  Vel_cmd  in  the 
loop.  The  HITL  switch  will  control  which  test  is  desired:  the  computer  actuator  model  or 
the  actual  hardware.  Table  II  summarizes  these  switch  functions.  The  interactive 
animation  page  used  to  monitor  and  control  the  model  is  shown  in  Figure  5.8. 


Table  II:  Simulation  States 


Speed  Controller 


Figure  5.8:  IA  Screen  for  HITL  Test 


The  HITL  design  includes  a  variable  gain  block,  which  permits  the  user  to  adjust 
the  gain  during  the  testing.  The  gain  margin  can  be  found  experimentally  by  running  the 
HITL  test  and  slowly  increasing  the  gain  until  the  system  goes  unstable.  The  results  are 
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VI.  ALTITUDE  CONTROLLER  DESIGN  PROJECT 


This  chapter  details  the  design  and  implementation  of  a  digital  controller  utilizing 
the  rapid  prototyping  system.  Applying  classical  control  techniques,  the  goal  is  to  design 
a  PI  controller  to  be  implemented  on  the  UAV  FROG  that  will  track  constant  altitude  in 
steady-state. 

A.  DESIGN  REQUIREMENTS 

Design  a  PI  controller  for  the  combined  model  of  the  FROG  and  autopilot  that 
satisfy  the  following  requirements: 

•  The  feedback  system  must  be  stable. 

•  The  steady  state  tracking  errors  to  constant  altitude  commands  must  be  zero. 

•  The  overshoot  to  step  commands  in  altitude  should  not  exceed  20%. 

•  The  rise  time  in  response  to  a  step  altitude  command  should  be  about  30 
seconds  for  a  100  ft  climb. 

B.  FROG  AND  AUTOPILOT  MODELS 

The  first  step  in  the  design  process  is  to  create  a  model  of  the  aircraft.  This 
model  is  developed  from  the  equations  of  motion  for  the  platform.  A  nonlinear  model  is 
first  formed  in  a  block  diagram  representation  of  these  equations.  The  nonlinear  model  is 
then  linearized  about  a  desired  trim  point  to  create  a  linear  model.  There  is  also  an 
autopilot  installed  in  the  FROG  that  must  be  modeled.  The  autopilot  controls  the  elevator 

and  aileron  to  command  constant  climb  rate  hc  and  constant  yaw  rate  rc.  The 
SystemBuild  model  for  the  combined  FROG  and  autoplot  was  developed  by  a  previous 
thesis  student  [Ref  7]  and  is  shown  in  Figure  6.1,  see  Figure  B.4  for  the  autopilot 
SuperBlock. 
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Gain  [dBJ 


To  determine  the  bandwidth  available 


the  control  bandwidth  is  first 


determined.  Figure  6.2  shows  the  -3db  cutoff  frequency  equal  to  2  rads/sec. 


h_dot  r 


Figure  6.1:  FROG  and  Autopilot  Models 


Output  1 


C.  FEEDBACK  CONTROLLER  DESIGN 


The  next  step  is  to  design  a  PI  controller  that  satisfies  the  requirements  outlined  in 
section  A.  This  is  an  iterative  process  employing  various  methods  with  the  controller 
gains  being  the  design  knobs  used  to  meet  requirements  of  response  time,  overshoot,  and 
command  and  control  loop  bandwidths. 

Applying  classical  control  techniques,  the  initial  controller  gains  are  generally 
first  obtained  for  continuous-time  model.  After  a  satisfactory  response  is  achieved  the 
system  is  transformed  to  discrete-time  and  tested  again  for  satisfactory  response. 

1.  Basic  SystemBuild  Model 

The  basic  model  is  constructed  with  a  PI  controller  and  the  complete  FROG, 
autopilot,  and  actuator  model  developed  in  the  previous  chapter,  and  all  known  delays 
and  nonlinearities.  The  known  delays  include:  a  transmission  delay  of  200  milli-second 
between  the  ground  station  and  the  FROG ,  and  an  update  rate  of  approximately  one 
second  for  the  Global  Positioning  System  (GPS)  position.  To  model  the  GPS  a  ZOH 
function  is  developed  using  a  discrete  gain  block  with  magnitude  one  and  a  sampling  rate 
of  T=  1  (sec).  The  complete  system  is  shown  in  Figure  6.3. 
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Figure  6.3:  Basic  SystemBuild  Model  for  Altitude  Controller 

The  following  values  of  the  PI  controller  gains  were  calculated  to  achieve  the 
design  requirements: 
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Figure  6.4:  Step  Response  for  Initial  Design 


A  number  of  unsuccessful  iterations  were  tried  to  reduce  the  overshoot  of  the  step 
response  while  maintaining  system  stability.  The  nonlinear  system  is  linearized  as 
described  in  the  next  section.  The  linear  model  is  then  analyzed  using  root-locus 
methods  and  Bode  frequency  response.  The  analysis  is  demonstrated  below. 

Consider  the  system  transfer  function 

»  L(s)  (K/„*Kryp(s) 

K  l  +  m  1  +(K/s+Kr)-P(s) 


where 


L(s)=C(s).P(s) 


This  results  in  an  extra  zero  in  the  numerator  at  ,  causing  the  overshoot. 

Therefore  a  second  design  was  developed.  The  PI  controller  was  modified,  as  shown  in 
Figure  6.5. 


Figure  6.5:  Modified  PI  Controller 


Now  the  system  transfer  function  is 


This  system  was  implemented  using  delta  implementation  [Ref.  8],  as  shown  in  Figure 
6.6.  Note  that  SystemBuild  does  not  have  a  differentiator  block,  therefore  the  following 
approximation  is  used: 


s  -> -  ,  where  e  «1 

ss  + 1 


This  design  showed  a  significant  reduction  in  the  amount  of  overshoot.  The 
system  response  is  shown  in  Figure  6.7.  The  initial  value  for  Kt  produced  a  slower  then 
desired  response  and  was  increased  to  .2  rads/sec.  With  a  satisfactory  step  response 
observed  in  position  and  climb-rate,  another  simulation  was  run  to  check  aircraft 
response  to  altitude  commands,  Figure  6.8. 
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Figure  6.7:  Step  Response  for  PI  Controller 
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Figure  6.8:  Dynamic  Response  of  Model 
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2.  Linearized  Model:  Further  Analysis 


To  determine  the  stability  margins  of  the  system  the  root-locus  and  Bode  analyses 
were  done.  The  loop  between  the  controller  and  plant  was  broken,  Figure  6.9,  and  the 
system  was  linearized.  The  interactive  root-locus  feature  of  Xmath  was  used  to 
determine  the  location  of  the  system  poles  and  the  gain  margin.  The  final  results  are 
shown  in  Figure  6.10,  with  a  gain  margin  of  -16db.  The  Bode  plot  was  then  generated 
and  the  command  bandwidth  of  0.2  rads/sec  and  the  phase  margin  of  70  degrees  were 
obtained,  Figure  6.11. 

The  system  was  then  discretized  by  transforming  the  SystemBuild  block  diagram. 
Note:  delay  blocks  must  be  added  to  each  integrator  to  avoid  algebraic  loop  in  RealSim. 
The  differentiator  approximation  used  here  is: 


— T' =--(i-z"') 

z-l  T  V  ' 


The  discrete  model  is  shown  in  Figure  6.12. 


Figure  6.9:  Broken  Loop  Block  Diagram 
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Figure  6.12:  Discrete  Altitude  Controller  Model 


D.  HARDWARE-IN -THE-LOOP  TEST 

The  next  step  is  a  hardware-in-the-loop  test.  The  actuators  on  the  AROD  set  up  in 
the  avionics  lab  are  the  same  actuators  that  control  the  elevator  for  the  FROG.  Therefore 
the  HITL  test  can  be  conducted  as  described  in  the  HITL  section  of  this  thesis.  The 
necessary  conversion  blocks  for  the  PWM  output  signal  and  voltage  input  signal  were 
added  to  the  controller  design.  Since  the  elevator  command  from  the  autoploit  and 
FROG  model  is  in  radians,  two  more  blocks  were  added  to  convert  degrees  and  radians. 
The  HITL  SystemBuild  model  for  the  HITL  testing  is  shown  in  Figure  6.13  and  the  test 
results  are  shown  in  Figure  6.14. 


E.  IMPLEMENTATION  AND  FLIGHT  TEST 
1.  Implementation 

The  final  step  is  to  implement  the  controller  into  the  flight  management  system 
for  the  FROG.  This  system  manages  a  number  of  functions  including  navigation  and 
flight  control.  The  SuperBlock  structure  of  the  flight  management  system  is  separated 
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into  five  lower  level  SuperBlocks  according  to  their  function.  The  altitude  controller  is 
inserted  into  the  control  SuperBlock  as  shown  in  Figure  6.15.  Appendix  B  contains  the 
hierarchy  for  the  SuperBlocks  that  make  up  the  complete  flight  management  system. 

The  UAV  can  be  controlled  by  either  the  computer  or  RC  pilot  with  a  standard 
RC  Futaba  transmitter.  A  complete  description  of  the  FROG  and  its  components  is  given 
in  [Ref.  9].  To  prevent  large  control  inputs  during  transitions  from  RC  pilot  to  computer 
control,  the  altitude  controller  is  implemented  using  a  delta  altitude  as  the  input 
command.  As  an  example,  if  the  user  desired  to  maintain  level  altitude  at  hand  off,  a 
command  of  zero  should  be  given.  A  script  block  is  used  to  freeze  the  GPS  altitude 
position  at  hand-over.  The  delta  commanded  altitude  is  then  summed  with  the  frozen 
altitude  position  and  is  used  as  the  entered  altitude  command  for  the  controller.  The 
controller  outputs  a  climb-rate  command  to  the  autopilot.  The  feedback  loop  uses  the 
GPS  altitude  position  referenced  with  respect  to  the  local  tangent  plane  (LTP)  at  the  field. 
The  orientation  of  the  frame  is  specified  as  North-East-Down  (NED),  therefore  a 
conversion  gain  is  added  to  the  feedback  loop  to  reverse  the  sign.  A  conversion  gain  is 
also  added  to  the  controller’s  output.  The  FROG  autopilot  model  differs  from  the  actual 
autopilot  in  the  units  used  for  the  entered  climb-rate  command.  The  model  uses  (ft/sec) 
where  the  actual  autopilot  uses  (ft/min).  The  two  switches  are  part  of  the  wind  down 
loop.  If  either  or  both  switches  are  in  the  “OFF”  position,  the  integrator  is  forced  back  to 
its  initial  value.  This  is  done  to  prevent  initiation  of  the  controller  at  a  previous  state. 

Once  the  controller  is  added  to  the  flight  management  system,  the  user  interface  is 
added  in  the  Interactive  Animation  screen  used  to  monitor  and  control  the  FROG.  The 
necessary  input/output  devices  are  added  to  the  existing  throttle  control  IA  page,  shown 
in  Figure  6.16.  For  the  initial  flight  testing,  the  screen  is  designed  to  display  a  number  of 
performance  variables  not  normally  used  for  an  operational  flight  display.  These  displays 
help  evaluate  whether  the  controller  is  working  properly.  The  two  digital  output  displays 
show  the  commanded  altitude  and  the  actual  GPS  altitude  in  feet.  When  the  altitude 
controller  is  operating  and  working  properly,  the  altitude  readouts  should  match.  An 
open  loop  input  for  the  climb-rate  is  also  added.  With  this  feature  the  climb-rate 
command  can  be  given  directly  to  the  autopilot  by  the  user.  The  input  slide  gage  is  added 
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to  adjust  the  gain  during  the  test.  The  trainer  light  in  the  middle  of  the  page  indicates 
who  is  controlling  the  vehicle,  the  computer  or  the  pilot. 


Figure  6.15:  Altitude  Controller  SuperBlock 


Figure  6.16:  IA  for  Altitude  Controller 
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2.  Flight  Test 


The  flight  test  is  conducted  at  a  RC  modelers  club  airfield  located  near  the  Naval 
Postgraduate  School.  The  RPS  is  completely  portable,  and  fits  easily  in  a  car  for 
transport  to  the  field.  A  flight  plan  is  written  a  couple  of  days  prior  to  the  flight 
describing  the  conduct  of  the  test  flight.  After  all  flight  checks  have  been  completed,  a 
face-to-face  pilot  briefing  is  given  to  review  the  flight  conduct  and  hand-off  procedures. 
Normally  the  hand-off  is  accomplished  during  steady-state  level  fight. 

Eight  test  runs  were  performed  during  two  test  flights.  The  data  acquisition  editor 
feature  of  the  RealSim  software  was  used  to  record  the  data.  For  each  test  run,  the 
Airspeed  Controller  was  used  to  maintain  constant  airspeed.  The  first  three  runs  tested 
the  performance  of  the  Altitude  Hold  Controller  in  a  turn.  From  the  ground  station,  it 
appeared  the  controller  maintained  altitude  within  a  +50  ft  band.  The  next  three  runs 
tested  the  controller’s  performance  in  response  to  climb  commands.  A  100  ft  climb 
command  was  given  from  a  straight  and  level  altitude.  Each  time  the  controller 
responded  well  to  the  climb  commands  and  leveled  off  appropriately.  Once  level,  the 
FROG  seemed  to  be  chasing  altitude.  From  observation,  it  was  concluded  the  controller 
was  chasing  altitude  due  to  GPS  drift.  Secondly,  the  aircraft  was  making  rapid  changes 
in  pitch  intermittently  due  to  the  latency  in  GPS  data,  as  seen  in  Figure  6.17.  To  reduce 
the  pitch  activity  a  filter  (s/s+3)  was  added  to  filter  GPS  altitude.  Two  more  runs  were 
conducted  with  the  filtered  GPS  data. 

The  test  results  for  the  controller  in  a  turn  are  shown  in  Figure  6.17.  The  altitude 
error  and  commanded  climb-rate  from  the  controller  show  correct  operation.  As 
expected,  the  drift  in  the  GPS  caused  the  controller  to  chase  altitude.  The  data  shows 
many  gaps  of  3-5  seconds  with  no  GPS  update.  Figure  6.18  details  the  results  from  the 
climb  commands.  As  designed,  the  controller  climbed  to  altitude  and  smoothly  leveled 
off.  The  commanded  climb-rate  was  well  within  the  aerodynamic  limits  of  the  FROG 
and  appropriate  for  the  climb.  The  performance  of  the  controller  with  the  filtered  GPS, 
shown  in  Figure  6.19,  was  unstable  with  the  errors  slowly  growing. 

Overall,  the  Altitude  Controller  performed  as  designed.  The  commanded  climb- 
rate  in  response  to  the  altitude  error  is  good.  The  shortfall  is  the  GPS  sensor.  Current 
plans  include  upgrading  the  FROG's  pitot-static  system.  With  a  reliable  altimeter  used  as 
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Figure  6.18:  Flight  Test  Results  for  Climb 
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VII.  CONCLUSIONS  AND  RECOMMENATIONS 


A.  CONCLUSIONS 

The  Advanced  Controls  of  Aerospace  Vehicles  course,  offered  at  the  Naval 
Postgraduate  School,  provides  an  excellent  opportunity  for  students  to  apply  classical  and 
modem  control  methods  to  the  design  of  basic  controllers.  A  strong  foundation  is 
presented  on  the  operations  and  analysis  of  sampled-data  systems.  The  rapid  prototyping 
system,  developed  by  the  department,  is  an  excellent  design  tool  and  allows  the  student 
valuable  hands-on  experience  in  the  design,  implementation  and  flight  testing  of  control 
algorithms  for  unmanned  air  vehicles.  The  ability  of  the  application  software,  RealSim, 
to  automatically  generate  higher-language  code  and  eliminate  the  time  consuming  task  of 
programming  the  code  for  a  working  model,  enables  design  projects  ample  time  to  be 
completed  in  the  twelve  weeks  allotted  for  the  course. 

Even  though  the  RPS  is  still  in  its  initial  stages  of  development,  it  has  generated  a 
number  of  thesis  opportunities,  with  many  more  foreseen  in  the  future.  Utilizing  mostly 
off-the  shelf  technology,  the  cost  of  this  educational  tool  will  be  minimal 


B.  RECOMMENDATIONS 

Considering  the  conclusions  stated  above  and  the  knowledge  gained  in  the  course 
of  instruction  given  in  the  Advanced  Controls  of  Aerospace  Vehicles,  the  following 
recommendations  are  forwarded: 

•  Investigate  scheduling  this  course,  and  its  prerequisites,  earlier  in  the  avionics 
curriculum.  The  UAV  program  developed  by  the  department  produces  many 
excellent  opportunities  for  thesis  work.  To  allow  ample  time  for  students  to 
complete  their  thesis  work,  this  class  should  be  scheduled  prior  to  the  last 
quarter  of  instruction. 

•  Presently  there  are  no  elective  courses  offered  by  the  aeronautical  engineering 
department  in  the  area  of  digital  control.  Investigate  the  establishment  of  an 
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elective  course  that  would  introduce  to  the  student  system  identification 
methods  and  advanced  multivariable  and  optimal  control  procedures. 

•  Devote  more  classroom  time  to  Design  of  Digital  Control  Systems  Using 
Transform  Techniques  presented  in  Chapter  V  of  [Ref.  1],  and  Design  of 
Digital  Control  Systems  Using  State-Space  Methods  presented  in  Chapter  VI 
of  [Ref.  1].  Less  time  should  be  given  to  Chapter  II  of  [Ref.  1],  Linear, 
Discrete,  Dynamic-Systems  Analysis:  The  z-Transform.  Material  covered  in 
chapter  2,  discrete  Fourier  transform  (DFT),  z-transform,  and  block  diagram 
descriptions,  should  be  introduced  during  the  prerequisite  course,  EO  2402, 
Introduction  to  Linear  Systems. 

•  Establish  a  library  within  the  avionics  lab  containing  all  previous  thesis  work 
and  material  related  to  the  UAV  FROG.  Many  of  the  design  projects  and 
future  thesis  work  will  build  on  the  work  from  past  projects.  Good 
documentation  is  required  to  keep  track  of  modifications,  input/output 
variables,  and  improvements  made  to  the  system. 

•  Purchase  a  second  target  computer  to  supplement  America.  Currently  the 
computer  lab  has  only  one  computer  with  the  AC  100  model  set-up  and  often 
two  or  three  students  end  up  waiting  for  access  to  America  to  compile  and  link 
their  programs  or  to  run  the  hardware  setup. 
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APPENDIX  A:  HCE  SCREENS  FOR  HITL  PROJECT 


- - —  Use  left  mouse  button,  tab,  shift-tab,  or  return  tp  select  items. 

Hints  Use  middle  mouse  button  on  toggle  items  for  pull-down  menu's. 
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Figure  A.1:  HCE  Input  Screen 
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Figure  A.2:  HCE  Output  Screen 
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Flight  Management 


APPENDIX  B:  ADDITIONAL  SUPERBLOCK  DIAGRAMS 


Figure  B.l:  Flight  Test  SuperBlock 
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Figure  B.2:  Flight  Management  SuperBlock 
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Airspeed  Controller 


Figure  B.3:  Control  Block  SuperBlock 
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Figure  B.4:  FROG  Auotpilot  Model 
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